![]() |
|||
![]()
|
![]() |
![]() Click Here! |
![]() |
PUBLIC KEY CERTIFICATES When a user sends a private E-mail message using the public key cryptography systems available todayfor example, privacy enhanced mail (PEM) or Pretty Good Privacy (PGP)they must obtain the recipients public key. For recipients to verify the senders electronic signature on a document, they must have the senders public key. To obtain someones public key, yet be assured that no one has tampered with it (e.g., that a phony key has not been issued to impersonate the sender), systems administrators must accept a public key only if it is certified. Certifying authorities, or trusted third parties, create a certificate by notarizing the key holders public key with their signature after validating the key holders proof of identity. The certificate is a bond between public key holders and their public key that is vouched for by the certifier. The validity of public key certificates must be checked before the public keys are used. If the certifiers signature does not check out, the public key or other parts of the certificate (e.g., the name) have likely been altered. The manner in which trust is conferred to the certifying authority is called a trust model. PRIVACY ENHANCED MAIL (PEM) AND PRETTY GOOD PRIVACY (PGP) Two secure E-mail systems are currently being implemented: Privacy Enhanced Mail (PEM) and Pretty Good Privacy (PGP). Each one uses a different trust model to validate certifying authorities. PEM, for example, has a trust model based on a hierarchical structure of certifying authorities. Privacy Enhanced Mail (PEM) PEM is the standard proposed by the Internet Engineering Task Force (IETF) that defines procedures for message encryption and authentication services (via digital signatures) for electronic mail transfer on the Internet. PEM is specified by IETF documents RFC1421 - RFC1424.
PEM is compliant with the Public Key Cryptography Standards (PKCS) developed by a consortium headed by RSA Data Security, Inc. and several software developers, including Apple, Novell, Lotus, Microsoft, Fischer International, and Sun Microsystems. PEM is capable of specifying the cipher algorithms it is using. It puts all messages into a canonical form before any cipher or hash operations are performed on them, and ensures that secure E-mail can be interchanged following PEM Internet standards. PEM enables users to do the following:
PEM messages use unencrypted headers to identify what type of processing was performed and which algorithms were used. The fields in the headers contain more information for the recipient to use when determining the validity of the message, including the public key certificate, the encrypted symmetric key for encoded messages, the message integrity check (MIC) field to indicate the validity of a message and whether it has been digitally signed, and the message itself. The data encryption key, MIC, and the message are encrypted only if indicated in these header fields. Issuing PEM Public Key Certificates A certifying authority (CA) can be any trusted central administrator willing to vouch for the identities of those whose keys it certifies. CAs should follow the comprehensive ITU-TSS X.509 standard recommended for certificates and CAs. The CA may be the only party from which to obtain a public-private key pair in certain high-security locations. In a company setting, a potential employees information is verified at the time of employment, so usually only employees and their managers signatures are required on a form. If an employee can generate a public-private key pair, he or she sends the self-signed public key with required proof of identity to an appropriate company CA to be certified. CAs may issue certificates based on varying levels of identification verification of the key holder. Online CAs are becoming increasingly necessary to satisfy the growing security demands of the information superhighway. Banks and major credit card companies will likely assume this role and issue their own public-private key pairs. These companies may well use identity verification as their sole key certification. Exhibit 8-6-1 presents an example of a PEM hierarchy of certification authority.
Determining When PEM Public Keys Are No Longer Valid PEM keys are deemed invalid in the following instances:
|
![]() |
|
Use of this site is subject certain Terms & Conditions. Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details. |